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President’s Report 
Tom McDermott, N5EG 


Well, we're right in the middle of the dog days of summer. 
Temperatures in the low 100's, and THI's a little bit higher. 
Just the days we were looking forward to when we were in 
January, last! School started last week in Plano, in only a few 
more weeks signs of autumn will appear. Hamcom this last 
June had pretty good weather, with sunny skies, and reason- 
able temperatures. This year TAPR and TPRS both rented 
booths, and we put them together into the packet radio ‘suite’. 
The programs this year were shorter in duration due to Reid 
Hollingsworth's exclusive presentation period starting at 1 
PM. The programs werw very high in quality. I'd like to 
personally thank our speakers, all of whom put in a significant 
amount of time preparing for the seminar. By all accounts, it 
was one of the best we've put on in a long time. Unfortu- 
nately we were not able to acquire audio and video recording 
equipment this year - so the presentations will not be on the 
web. Our presenters were Allen Finne, KB5SQK, Mike 
Heskett, B5QLD, David Dennis, N5BOC, and Greg Jones, 
WDSIVD. It was nice to see actual presentations and multi- 
media content during the demos. Attendance at the meetings 
was quite good, we had a very large meeting room this year. 


(Continued on page 2) 
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(Continued from page 1) 

Three directors were elected by the members at 
the annual membership meeting - Bob Morgan, 
WB5AOH, and Jim Neely, WA5LHS were re- 
elected, while Mike Heskett, WB5QLD was elected 
as a new director - congratulations to all! The 
director positions are for two-year terms. The 
directors subsequently elected officers and other 
positions for TPRS, Inc. for one-year terms. 
Those appointed by the board are: President - 
Tom McDermott, N5EG, Vice President - Bob 
Morgan, WB5AQOH, Treasurer - Jim Neely, 
WASLHS, Newsletter editor - Brad Smith KC5SP, 
and Database manager - Frank Aguilar, NSSSH. 


In this issue you will find that Harry Ridenour, 
NOCCW, the TexNet network manager, has re- 
vised and updated the current TexNet node as- 
signment list - thanks, Harry. 


To update the status of the TAPR FHSS radio 
project: we brought on two additional members to 
the design team a few months ago, John 
Schroeder, K5ZMJ, and David Cummings, 
WASTET. John and David have been working on 
revising the RF board. We found that due to a 
miscommunication with our board shop, that the 
dielectric thickness between the board core and 
the outer signal layers was only 7.5 mils, instead 
of the expected 25 mils. This lowered the effective 
impedance of the 50-ohm microstrip lines down to 
21 ohms, which has caused problems with the RF 
signal levels. Additionally, several of the RF 
components that we used on the original layout of 
the RF board have since been discontinued. So 
John and David are redesigning the RF board to 
eliminate those parts, and substitute for them 
more general-purpose parts that we hope will have 
a longer production lifetime. 


A more difficult part cancellation was that of the 
Motorola MC145750 QPSK modulator compo- 
nent. This part provided a number of functions in 
a single, compact IC. Unfortunately only having 
available limited documentation we were not able 
to get the phase-locked loop on it to operate. This, 
coupled along with it's production cancellation has 
forced us into a difficult redesign. Several years 
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ago this type of redesign would have been virtually 
impossible for us to cope with, but thanks to im- 
proving FPGA technology, we are going to imple- 
ment the baseband FIR filters for the modulator in 
a Xilinx FPGA (Field programmable Gate Array) 
component. One of the great difficulties with high- 
speed digital data radios is implementing the mod- 
ulation filters. We need a large number of taps with 
a significant amount of precision of the coefficient 
values. The processing requirements (high data 
rate, lots of taps) places the computational load 
beyond what almost any general-purpose software- 
programmable DSP chip is able to accomplish. 
Fortunately, Xilinx has released a ‘core’ generator 
for their FPGA parts which implement in bit-serial 
arithmetic symmetric and non-symmetric FIR 
(Finite Impulse Response) digital filters. Our com- 
putation shows that they will be just fast enough to 
implement our modem filters. These filters will 
provide sinc-compensated square-root of raised- 
cosine shaping to the transmit baseband I- and Q- 
channels. This logic will be added to new logic we 
have to generate for differentially-coding and word- 
formatting the QPSK symbols. Previously, we had 
also implemented the symbol-timing recovery logic 
in a small FPGA for the Harris QPSK demodulator, 
so we can put all of these different logic functions 
into a single Xilinx device. 


Current estimates are that it will take about 30,000 
gates of logic to fit all of this into a single FPGA. 
We've identified the proper parts, and the costs are 
within the design tolerance. Fortunately, the part 
comes in a 100-pin quad leaded flat-pack that is 
amazingly small, so Bob Stricklin, NSBRG is confi- 
dent he can fit it and a new dual D/A converter all 
onto the existing digital board. The D/A converter 
is from Analog Devices - it provides 2x interpolation 
of the signals which reduces the demands on the 
reconstruction filters after the analog output port. 
All the parts are surface-mount, and the FPGA has 
small lead spacing (about 20 mils) like the Mo- 
torola processor part (get out your microscope to 
probe these parts!). 


All of these changes will result in the interface 


between the digital and analog radio boards being 
changed to baseband I- and Q- in both the transmit 
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and receive directions. One benefit of doing this is 
that we will be able to test many of the receiver 
functions of the digital board by looping back the 
transmit signals to the receive signals. It also 
removes all of the digital baseband processing 
form the RF board - so hopefully the RF board will 
be easier to port to new frequencies in the future. 


Hopefully by the time you read this, we will have 
design kits for the Xilinx components, and can start 
coding and testing some of the logic. The Xilinx 
parts contain internal RAM to implement the logic 
configuration of the gates. Normally, a serial 
FLASH prom is used on the PC board to load the 
Xilinx part with it's logic functionality. We are 
instead going to implement a loader in the 68360 
microprocessor. This will allow us to put all of the 
logic for the part into the software configuration of 
the radio, and alter the actual logic in the part with 
updates to the software, only. The code will be in 
the microprocessor's FLASH memory, and the pro- 
cessor will download the FPGA during the boot-up 
time. 


Unfortunately, all of this redesign and component 
substitution has of course delayed the project sig- 
nificantly. Our hope is that by beefing up the 
design staff we can put the RF and baseband 
design efforts in parallel, and keep things moving. 
I'll advise in subsequent issues of the Quarterly 
Report about the status of the project, and what 
lessons we've learned in trying to implement DSP 
functions within programmable logic. One lesson 
learned is that ham radio projects now have to be 
finished within the production lifetime of the com- 
ponents used on the project - and those times are 
shrinking FAST! 

-30- 
SS ee 
TPRS, Inc. Financial Status 
Jim Neely, WA5LHS 


We deposited $1295.00 from HamCom. Our end of 
June balance is $5970.14. There are two reim- 
bursement checks outstanding, for a total of 
$87.77. Hamcom expenses this year were for 
booth rental. 


Jim Neely, WA5LHS, Treasurer 
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BATTERIES 


(from Internet newsgroup postings) 


Dr. Robert Suding WOLMD 
Conifer, Colorado 


Lead batteries (wet, gel or solid) are voltage 
charged. This means that the charging voltage is 
held constant and the battery's voltage rises until 
it matches the charging voltage. As the battery's 
voltage approaches the charging voltage the cur- 
rent tapers off to near zero. A 12v lead based 
battery is charged to around 14.5 volts. 


When the battery voltage measures 14.5 volts, the 
charging voltage is reduced to around 13 volts, 
called a "Float" value. Most good batteries will 
float at about 13.25 volts indefinitely, thus seeing 
no charge. Should the battery voltage fall below 
13 volts, the 14.5 volt charge is reapplied. 


Most wallwart 1 amp lead trickle chargers keep 
charging away, and drastically shorten the life of 
the lead battery. By putting a couple of series 
diodes in the + lead (include a shorting switch for 
full charge) the wallwart's output voltage can be 
trimmed back to provide the float charge manu- 
ally. 


Full charge of a lead battery is ~13.25 volts and 
end of charge is ~11volts. Replace the battery 
when it does not keep the 13.25 volts for a couple 
of days off the charger. 


Nicad batteries are current charged. A typical 
wallwart nicad charger delivers a higher voltage 
dropped through a fixed resistor that sets the 
average current throughout the charge period to 
around the C/10 value mentioned by W7EL. As 
the battery is charged, its terminal voltage rises 
but the current stays somewhat constant. Nicads 
are traditionally charged for about 16 hours at this 
C/10 rate. After the battery is fully charged, any 
further charge is converted to heat (BAD, BAD, 
BAD!) When a nicad battery reaches 120 degree F 
(not uncommon on a hot day outside), it loses 


(Continued on page 5) 
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Texas Packet Radio Society, Inc. 


TPRS was founded in 1985 and is an educational, public service, and scientific 
research non-profit corporation. Texas Packet Radio Society goals are: 


1- design and research amateur radio packet networks 
2- provide education in the area of general packet usage 


To accomplish better communications in the region, TPRS has been 
organizing statewide working groups to cover various networking topics. The 
current working groups are the Mailbox/BBS Group, TCP/IP Group, and the 
TexNet Support Group. TPRS hopes that these working groups will help 
promote information exchange in their respected areas in Texas. New working 
groups are formed as needed to provide channels for discussion and to help 
provide direction for that area of digital communications. Anyone can participate 
in a working group; TPRS membership is not required. 


TexNet 

TPRS has established a digital packet network protocol, a standard 
hardware package for the network nodes, and software modules that implement 
the TexNet network. 

The basic design philosophy of TexNet is an open, inexpensive, multi- 
resource, high speed ‘backbone’ with access through multi-connect capable local 
nodes. On the high speed side, TexNet is a 9600 baud network system. For local 
access, compatibility with the typical 2 meter AX.25, 1200 baud, AFSK/FM. 
station is the operational norm. Other baud rates and modulation techniques can 
be supported on the primary user port or secondary port. The system is totally 
compatible with both versions of the AX.25 protocol specifications for user 
connections. With these general specifications, TexNet has been designed and 
tested to enable all users to take advantage of this high speed, full protocol 
protected packet network system. 

Each node offers, in addition to TexNet access, local area digipeater service, 
2 conference bridges for full protocol protected roundtable or net operation, a full 
mult-connect, multi-user mailbox system, a local console for installation and 
maintenance setups, a debugger module for long distance and local software 
monitoring,and an interface for a weather information server for regional weather 
information, if available. 

The NCP-PC (TexNet for PC) creates a direct interface to the PC platform. 
The Z80 based PC card supports 4 channels for communications. This co- 
processor approach allows the AX.25 and TexNet-IP to run on the card without 
affecting the PC. This allows the full power of the PC to be used for network 
applications. The versatility of this board is only now being developed and 
applications are endless. 


The TexNet Network 
The Texas TexNet network system has been operational since October 
1986. When fully operational, the network reaches from the border of Mexico to 
Missouri. Use of the Texas TexNet system is open to all amateur operators. 
TPRS has been coordinating the installation of the Texas TexNet system. Further 
expansion of the system depends entirely upon the amateur community. 


INFORMATION 
TPRS is interested in spreading our information and research efforts as 
widely as possible. We want other groups involved with packet efforts to get in 
contact with us. We will provide information for those amateur packet groups 
that are interested in this system for their areas. If you would like more 
information concerning TPRS or TexNet, please drop a letter to: 


Texas Packet Radio Society, Inc. 
P. O. Box 50238 
Denton, Texas 76206-0238 


TPRS MEMBERSHIP 
TPRS membership is widespread with most members located in Texas, but 
members are located in other states and in foreign countries. Membership is 
open to any interested person. If you are interested in becoming a member and 
receiving the TPRS Quaterly, please send your name, address and call with 
membership dues of $12 per year. A membership application is available 
elsewhere in this issue. 
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40% of its capacity, and does not recover this 
capacity completely after cooling. 


A new nicad pack will lose its charge in ~ 1 month. 
To prevent overheating after reaching full charge, 
yet maintain the full charge level, the nicad pack 
should be put on a "Trickle" charge which just 
replaces the energy lost due to self discharge. This 
is commonly set to C/50, though new batteries lose 
less and could be set to C/200 just as well. The 
nicad's wallwart could have a resistor (with a shunt- 
ing switch for full charge) added. 


A fully charged nicad pack will measure about 1.45 
volts/cell. End of life is 1.2 volts/cell. Legally dead 
is 1.1 volts/cell, but the amount of time during use 
between 1.2 volts/cell & 1.1 volts/cell or less is 
often measured in minutes due to the rapid down 
slope of the "death curve", which starts at 1.175 
volts on a new battery! 


As nicads age, the end of charge terminal voltage 
goes up, often exceeding 1.5 volts/cell, as does the 
initiation of the "death curve" point to about 1.225 
volts/cell. The inter plate insulation inside the cell 
also breaks down and the battery self discharges 
faster, and will eventually short out if not main- 
tained on a trickle charge. 


| replace the nicad pack if the full charge voltage 
while on trickle charge exceeds 1.5 volts, or if the 
battery does not maintain >1.2 volts/cell when left 
to self discharge for 1 week. 


Metal hydride batteries are operationally similar to 
nicads, except that they self discharge in 2 weeks. 


For more information and diagrams, you can ac- 
cess my battery seminar notes that | use at the 
Toledo R/C show each year at 


http:/Avww.ultimatecharger.com 
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Providing Wireless Internet access 
through intermediate routers. 
Joe Borovetz, WA5VMS 


When | left off in the Spring issue of the QR, | 
added a note telling that | had my link running and 
would go into greater detail in the next issue. Due 
to time limitations, | missed that issue. | hope the 
following update will clear up some of the missing 
details. 


Things started to fall in place when | was able to 
borrow a reference book on Cisco routers. The title 
of the book is "Cisco TCP/IP a Routing Profes- 
sional Reference" (Second Edition). It is available 
through amazon.com or at most major book stores 
(such as Barnes & Noble). This book is written 
about the Cisco 2500 and describes the 2500 
setup, which is convenient, since my Internet Ser- 
vice Provider (ISP) uses a 2500. | spent quite a bit 
of time reading the chapters that covered routing 
protocols and routing issues. If you look past the 
Cisco-specific portions of the book, there is a 
tremendous amount of information on routing and 
routing protocols. It is well written in clear, easy to 
understand terminology. The figure on page 6 
shows a diagram of my setup, which will be refer- 
enced in the rest of the article. 


RIP Routing Protocol 


This book provides an in-depth explanation of the 
RIP routing protocol and how to manage it’s use. | 
had some general management ideas before | read 
the section on RIP but learned how it works and 
why it is a useful tool. Before | continue further, | 
should explain why | needed to use RIP in the first 
place. My provider was reluctant to go into the 
routing tables on his Cisco 2500 and add the static 
routes that were needed to make my equipment 
work. The following example is similar to the type 
of entry that was needed in the 2500’s routing 
table: 

If we wish to reach a machine with the IP 

address of 192.168.0.3 and the packet 

have to travel through a remote TAL radio 


(Continued on page 6) 
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IP address 
192.168.0.2 


Ethernet 


\ connection y 


Internet Service Provider 
(ISP) Location 


(Continued from page 5) 
(which is also a router) which has an IP 
address of 192.168.0.2, we need an entry 
in the 2500 that says that in order to 
reach the .3 address, you must route 
packets through the .2 address (i.e. 
through the TAL router). 


The use of RIP to “supply” the correct routing 
information was the only option that | had in lieu of 
the routes being entered in the 2500’s permanent 
routing tables. In several networking documents, | 
read a number of bad things about RIP. While RIP 
does have some drawbacks, when it is managed 
properly it is a valuable tool. RIP is the only routing 
protocol that all machines in the TCP/IP world can 
recognize. While a particular device such as a 
router may not be able to use RIP to provide 
routing information to another machine, it can rec- 
ognize and set up routes using the information 
provided by RIP. TAL routers are able to provide 
routing information using the RIP-1 and RIP-2 
protocols. 


If you were looking for RIP on your linux 
machine, you would look for the com- 

mand “routed” - which stands for "route 
daemon". A daemon is a process in the 
unix environment that runs continuously 
(usually started up by the initialization of 
unix/linux) usually in the background. 
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IP address 
192.168.0.3 


Ethernet 


\. connection J 
My home 


My management of RIP was that it was only en- 
abled on the remote TAL router, the one that was 
talking directly to the Cisco 2500. The routing 
entries in the remote TAL radio were kept to a 
minimum. Only routes that were necessary for the 
system to work were entered into the tables on that 
router (adjacent to the ISP's 2500). This eliminates 
the possibility that RIP might publish to the internet 
a route that was meant to be “private”. There is an 
option when you set up routes in the TAL (for that 
matter any unix/linux machine) that allows you 
designate a route as being "private" and not one to 
be published. | chose not to enter any private 
routes in the tables on the remote TAL. In other 
words KISS. Keep it simple. 


In the linux world, there is a utility called “ocastd”. 
Allen Finne, KB5SQK told me about it. It is avail- 
able on the site ftp://metalab.unc.edu. The nice 
thing about bcastd is that it has the ability to supply 
routing data in a manner similar to RIP but with one 
important difference: the only routes that bcastd 
supplies are those that you specify at the time it is 
enabled. With bcastd, there is no chance of a 
private route making it out into the real world. If | 
were to install a PC running linux at my ISP, | 
would use bcastd for routing updates as opposed 
to routed (RIP protocol). 

Default Routes 


The next problem that | found was one that at least 
(Continued on page 7) 
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three other people including myself had over 
looked. We had checked and re-checked all of the 
static routes in my Linux machine and the two TAL 
routers. Everything looked fine. None of us could 
understand why things were not working. This was 
one of those times when we could not see the 
forest for the trees. This is another instance where 
the Cisco routing reference book came in handy. 
One simple statement in router setup made all of 
the difference. | had specified that the ethernet port 
on the remote TAL radio was the default route in 
the TAL config files. This makes that particular 
port the gateway to the world for everything down- 
stream of the TAL (on my side, away from the 
provider's 2500). The problem was that | neglected 
to specify a default gateway. In this case, the 
default gateway would be the IP address of the 
Cisco 2500 at my provider. 


In the TAL, the statement is similar to this: 
route add default ether 192.168.0.1 


where "ether" specifies the TAL ethernet port and 
the IP address is that of the gateway router or 
machine. This means the TAL radio at the ISP's 
office would forward packets to 192.168.0.1 (the 
ISP's Cisco 2500) if it did not know otherwise 
where to send them. The TAL radio/router in the 
ISP office only knows a few IP addresses - the TAL 
at my home, and the few TCP/IP boxes in my home 
network. Accessing the Internet via the radio link, 
for example, generates packets destined for ad- 
dresses unknown to the TAL. Thus they will be 
forwarded to the "default" address (in this case, the 
ISP's 2500 which knows how to send them to the 
Internet). 

The above example is the correct entry. Prior to 
this, | had used the following statement: 


Route add default ether 


Like | mentioned earlier, all of the folks that 
checked my routing tables had over looked this 
problem. The above statement obviously does not 
let the TAL radio in the ISP office know what to do 
with packets destined for the Internet. After this 
correction, things were working better but | still had 
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no connectivity. 


Address Resolution Protocol (ARP) 


During this same time period, | stumbled across 
some mini how-to documents on my linux CD ROM 
disk set. One of these was entitled “A Treatise on 
the use of proxy ARP”. In a phone conversation 
with Allen, KB5SQK, | discovered that he was 
working on a project with JNOS and DX Cluster 
linking. He had been reading the same how-to and 
we both decided that the use of proxy ARP would 
be necessary in order to make both of our systems 
work. What is proxy ARP? Before we can discuss 
proxy ARP, we need to look at ARP, the address 
resolution protocol. ARP is the tool used to put an 
IP address together with a hardware address. The 
hardware address is usually that of a particular 
device(in most cases, a network card) . 


If you were to do an ifconfig (interface configura- 
tion) command on a linux box, you would see a 
listing of the various network resources, consisting 
of a couple of network cards, some slip connec- 
tions, and a local loopback device. Along with the 
IP address, the network cards will have an entry 
similar to the following statement: 


HWaddr: 00:00:C0:03:67:D9 


The hardware address is unique for every ethernet 
card in existence and is set at the time the card is 
manufactured. This is where ARP comes in. ARP 
binds the IP address of 192.168.0.3 to the hard- 
ware address of 00:00:C0:03:67:D9 (at the time 
linux is booted up). The problem | ran into is this: In 
order for ARP to handle packets addressed to 
192.168.0.3, it has to receive the packets. The only 
device that my provider's Cisco router can see is 
the TAL router, and it has the IP address of 
192.168.0.2. ARP requests only travel on the local 
network and are thus not passed forward by 
routers, i.e. routers block ARP requests ( and ARP 
responses). 


(Continued on page 8) 
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Proxy ARP 


This is where proxy ARP comes in to the picture. 
Proxy ARP entries in the TAL router allow it to relay 
ARP requests from my linux box to the TAL ether- 
net port, and thus to my ISP's Cisco 2500 router. In 
simple terms, when the TAL receives an ARP 
request for the .3 address, it substitutes the hard- 
ware address of its own ethernet port and pretends 
to be 192.168.0.3 (it is a proxy for 192.168.0.3) and 
forwards the ARP request to the 2500. Similarly, 
proxy ARP in the TAL allows ARP responses from 
the Cisco 2500 to be returned over the radio link to 
my 192.168.0.3 linux box. Thus the Cisco 2500 
and my linux box successfully exchange ARP re- 
quests and responses over the TAL link, and 
through the TAL routers. This fools the Cisco 2500 
into thinking that my linux box is directly connected 
to the Cisco ethernet port 


In the linux networking how-to guide, "proxy ARP" 
is described as evil, and to be avoided at all costs 
(it is also sometimes known by the name "the ARP 
hack"). It may be evil to some folks but it has been 
great to me. The bottom line is that none of this 
system would work without the use of proxy ARP. 
The “evil” side of proxy ARP is that it can be used 
to create havoc by capturing packets sent to a 
legitimate host. It can also screw up a network if 
you have two hosts responding to the same ARP 
request. ARP is a protocol that completely trusts 
people and computers setting up IP addresses, it 
does not check against inconsistencies. The above 
explanation is somewhat abbreviated. It would take 
three or four pages to cover ARP and proxy ARP 
in-depth. 


command “ping tapr.org” and the pings were re- 
turned. 


The routing table modifications to the TAL routers 
consisted of building routes to both the Cisco router 
and the DNS server at my provider. These routes 
were also entered in my linux box. If you omit the 
route to the Cisco router, you have no access to the 
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real world. If you omit the route to the DNS box, it 
will not be possible to resolve an IP address. 


| guess that concludes what | had for this issue. 
Next issue, | will cover some additional issues that 
| have encountered when working with my provider 
and a system update along with details of the 
installation of the w5ejk linux box (running JNOS/ 
Linux) at the remote site. 


1999 ARRL and TAPR Digital Commu- 
nications Conference 
September 24-26, 1999 
Phoenix, Arizona 


It's that time again! Time to start making your travel 
plans and thinking about what to publish for the 
upcoming 18th Annual ARRL and TAPR Digital 
Communications Conference. 


The ARRL and TAPR Digital Communications Con- 
ference is an international forum for radio amateurs 
in digital communications, networking, and related 
technologies to meet, publish their work, and pre- 
sent new ideas and techniques for discussion. 
Presenters and attendees will have the opportunity 
to exchange ideas and learn about recent hardware 
and software advances, theories, experimental re- 
sults, and practical applications. The Digital Com- 
munications Conference is not just for the digital 
expert, but for digitally-oriented amateurs of all 
levels of experience. 


The 1999 ARRL and TAPR Digital Communica- 
tions Conference will be held September 24-26, 
1999 in Phoenix, Arizona. This year's conference 
location is just minutes away from the Phoenix Sky 
Harbor International Airport (PHX). 


Contact TAPR for more info, or to register for the 
DCC: 


Tucson Amateur Packet Radio 

8987-309 E. Tanque Verde Road #337 

Tucson, AZ 85749-9399. 

phone 940-383-0000, fax 940-566-2544 

e-mail tapr@tapr.org, browse http:/Awww.tapr.org 


Page 8 


TPRS Node Assigments 
Official Publication: August, 1999 
Subject to Corrections/Additions/Deletions. 


= ACTIVE/COMPL 
ACTIVE/TEST 
= PENDING 


City/Town Alias Call Remarks 


Dallas TEXNET WR5C PMS 
Richardson TESTBED W9DDD R&D 
Richardson RICH W9DDD R&D 
Murphy MURPHY N5SEG 
Austin NWS Unkn Weather 
New Braunfels STXWX NSIUT Weather 
Boerne BOERNE N5VUO 
Geronimo GERONMO WB5SNSN 
Austin AUSTIN WASLHS 
San Antonio ALA NOCCW 

Ss 

D 

L 


PMS (AKA 


Oe. 


San Antonio WA2MCT 
Denton W5SNGU 
Lubbock KC5KOF 
Midland ] WB5RXA 
Greenville K5GVL 
Midland WF5SE 
Rockport N5JKH 
Cy Christa. N5XCH 
Pettus KA5SBWL 
Lubbock KA5EJX DXCLUST!I 
Austin K5TR 

Austin W5TQ 

Victoria W5DSC 
Alice K5DYY 
Amarillo AMARILO WD5ILA 
Abilene ABILENE WBSEKW 
San Antonio SANTEX WB5FNZ 
Kingsville TAMUK W5ZD 7 
Bryan/CollStn  SBRAZOS KF5LN .05/446.10 
Bryan/CollStn NBRAZOS KG5ZD Pail (See Nr 43) 
Fannin County FANNIN WB5SRDD -05 

Sherman SHERMAN WBSCVR ~91 

South Dallas SDALLAS KF5RN 
Waco WACO WD5KAL 
Falfurrias FALFUR WB5FRO 
Mercedes VALLEY WSRGV : DXCluster port 2 
San Isidro ISIDRO K5RAV 
Brownsville BROWX K5RAV NWS node 
Fort Worth FTWORTH NSAUX 
AOHTST AUSTIN WB5AOH R&D AUSTIN 
TNC95 AUSTIN WB5AOH R&D AUSTIN 


DXCluster port 
-99/446.1 
05 


PRPPNPRPRPEPZRPRPRPER 
YORWUUUHS THGan 


(aka KINGVL) 


BRRPPNPRPRPRPEPR 
BRBRBHOBA BABA AD BD 


x 
P 
P 
x 
x 
x 
x 
x 
x 
P 
P 
x 
P. 
x 
x 
x 
P 
x 
x 
x 
x 
P 
P 
x 
x 
P 
P 
P 
Xx 
P 
Xx 
Xx 
Xx 
Xx 
Xx 
Xx 


E] 
d 
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TPRS Node Assigments 
Official Publication: August, 1999 
Subject to Corrections/Additions/Deletions. 
(Continued) 


(100-150) Reserved for TexLink Node Usage 
User 
Nr Status City/Town Alias Call Port 


105 xX Floresville FLORES WD5DOE None 
109 xX Refugio REFUGIO WB5OLT None 
118 Moody MOODY W5ZDN 440.1 


(151-249) Reserved for Non-Texas Node Usage 
(150-159) Reserved for Louisiana 


Lafayette | LFTDXC NSSYF 
BatonRouge ] BTRDXC N5VWM 
Maxie ] MAXIE K5USL 
Ft Gibson OK FTGIBSN N5SGIT 
Muskogee OK MKOTST WA5SVMS 
Muskogee OK MUSKOGE W5EJUK 
Lincoln AR AYETVL K5VR 

Clayton OK LAYTON W5CUQ 
Ft Smith AR [SMITH W5SANR 
Tulsa OK WTULSA W5IAS 
Tulsa OK I N5SWX 

Okemah OK WB5HLR 
Choctaw OK K5CAR 
Prarie Grove AR K5FXB None 

Garfield AR WB2ROC None 

Aurora Missouri KOSQS 145.05 
Mt Magazine AR KF5XB 144.95 
Russelville WB5BHS UNKN 

Little Rock AR 1 WB5SQK 144.97 
FUTURE) 
Little Rock AR 1 KA5SQK TEST Node 


Server 


PRPArPRPrRPrRPRAPR 
BHRHSHRARHB HABA 
Annu BROWOD WH 


-50 


£. 
e 
e 
x 
x 
x 
x 
x 
x 
x 
x 
x 
x 
? 
x 
x 
x 
x 
x 

( 
T 


(250-255) Network Reserved 


If you are a TexNet node opearator/owner and have a correction to make to 
the list, advise to NOCCW@K3WGF.#STX.TX.USA.NOAM, or leave a message for 
NOCCW on the NDALLAS PMS of TexNet. 
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TPRS Membership Application 


Name Callsign 
Address 

Apt. or Mailstop 

City/State 

Zip E-mail address 


Evening Phone (_) Work Phone (__) 


Membership is $12 per year. How many years are you paying for? 


New Member Renewal 


Make check payable to: Texas Packet Radio Society 


—-—----------Y 


ATIN: 


Membership Texas Packet Radio Society 


P.O. Box 50238 
Denton, Texas 76206-0238 


Texas Packet Radio Society, Inc. 


Wireless Internet Be sure to visit the TPRS web page: 
http://www.tprs.org 
Access for the latest information on TPRS 
activities. 
Battery Charging -_ 
A current listing of Packet nodes, 
woe frequencies, and networks is located in the 
1999 Digital North American Digital Systems 
Communications Directory (NADSD) on-line at: 
Conference http://www.tapr.org/directory/index.html 


OO A A AO A A A A A A A A A A A A A A A ae 


Texas Packet Radio Society 
P.O. Box 50238 
Denton, Texas 76206-0238 


ADDRESS CORRECTION REQUESTED 


To: 


